Erickson Methodology for Enterprise Architecture by Douglas T. Erickson

Author:Douglas T. Erickson [Erickson, Douglas T.]
Language: eng
Format: epub
ISBN: 9781532099953
Publisher: iUniverse
Published: 2020-12-20T05:00:00+00:00

This analytical construct got us on the wrong track. It is not that this approach was not useful because it is useful for designing processes. It turns out that it was not a very good way to identify what the enterprise business process architecture should be and how each business process integrates within the enterprise: nor did it do anything regarding identifying and defining an efficient and effective enterprise data architecture.

Additionally, the construct is typically applied in a backward sequence. First, you define the output data, then you defined the input data required to produce the output, and then you defined the process transformations necessary to take the input and produce the output. This approach did have the appearance of a fast path to develop and deliver functionality as fast as you can. To some extent, that was achieved. However, the cost and the consequences have been quite detrimental.

The advent of Structured Analysis and its use of Data Flow Diagrams was useful but perpetuated the “process first, data second” even though the word “data” was in the name of diagrams. This approach just continued the primacy of process over data.

The second or companion cause is the Job-shop project approach to developing applications and application databases. The project approach, driven by the constant pressure to deliver each project as fast as possible at the lowest cost per project, results in creating applications and application databases that inherently contain systemic, long-term cost and quality problems. A natural extension of this approach was the design and development of application-specific databases that create their own set of data cost and quality problems. Because these databases were constrained by project scope, the content and structure of the data were compromised because it was redundant throughout the application portfolio. This situation is an example of the classic “pay me now or pay me later” issue, and the “pay me later” option has been the overwhelming choice!

By the way, most IT professionals are still preserving this approach. There are many Data Administrators, Database Administrators, Data Analysts, and Data Modelers, but their impact on improving the situation is minimal. Data Administrators, Data Analysts, or Data Modelers are some of the most frustrated people in the Information Technology community today. “Data People” mostly function as servants to the “Process People,” and it even gets more complicated because many “Data People” spent their formative years as “Process People,” and that is what they know best.

This continuing approach results in the fragmented, dis-integrated applications, and databases that harbor the pervasive data problems. The following graphic displays the results of using the “Input-Process-Output” analytical construct to identify and design data and applications. However, each system was developed independently, project-by-project, over extended periods, by different people, using different approaches, and using different technologies.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.